Settings whitelist #892
Settings whitelist #892
Conversation
|
Waiting for feedback from @chris579. |
|
Like it! |
| // admin wildcard and local machine is logged in admin | ||
| if ("admin" in _whitelist && {IS_ADMIN_LOGGED}) exitWith {true}; | ||
|
|
||
| _uid in _whitelist |
There was a problem hiding this comment.
maybe _whitelist should be GVAR and set at mission init, then FUNC(whitelisted) become getPlayerUID player in GVAR(whitelist)
There was a problem hiding this comment.
no, "admin" in GVAR(whitelist) && {IS_ADMIN_LOGGED} || {getPlayerUID player in GVAR(whitelist)}
There was a problem hiding this comment.
But then you can't set it with addon.
There was a problem hiding this comment.
Would give the ability to dynamically add entries to the variables. Meaning admins with debug console access can just add themselves to the list. Which is exactly what the original Request wanted to prevent.
There was a problem hiding this comment.
Also true. But with the debug console, you can mess with the settings anyway if you know what you're doing.
There was a problem hiding this comment.
But then you can't set it with addon.
why? configFile/QGVAR(whitelist) should exist on mission init.
There was a problem hiding this comment.
you can mess with the settings anyway if you know what you're doing.
But not with config files.
But then you can't set it with addon.
Think commy missunderstood. ala GVAR != config.
I prefer the current state.
There was a problem hiding this comment.
Current state doesn't give any additional security because like commy2 said you can easily manage settings manually with debug console. But ability to change whitelist during mission could be helpful in some cases.
When merged this pull request will:
Adds
cba_settings_whitelist[]array to both addon and mission config (description.ext).The dedicated client/player can edit server tab settings if and only if any of these apply:
getPlayerUID) appears inside either arrayIf you want nobody to edit the settings, not even the logged in admin, then you can use a throwaway UID (e.g. "nobody") in either addon or mission config array.
By default, both of them are undefined/empty, so point #2 applies (logged in admin can edit the settings which is the current behavior before this PR).
In SP or as Local Host, you can edit the settings regardless of this whitelist.
This requires putting down UID's in either a global addon or the mission config, so if you're worried about spoofing, don't use it :~)
Future improvement could be made by comparing the players UID on the server instead, but I don't feel like writing a callback system for this stuff atm. This way you could use a server machine local addon to compare the UID.